 | Consigli tecnici.
 | Generali. Nel realizzare un'area,
bisogna sempre porsi dal punto di vista dei giocatori, cioe' di coloro che, in ultima
analisi, daranno un senso all'area stessa. Il fine ultimo, infatti, e' quello del
divertimento dei personaggi che vi trascorreranno il loro tempo. Ogni area deve avere una
storia unica e caratteristica, e deve essere dotata di una o piu' quest intrinseche (la
cui stesura e' oggi resa facile e veloce dai 'mob parlanti'), che assicurino un
divertimento al di la' del semplice xp-run (strage di mob per ottenere punti esperienza)
ed eq-hunting (caccia di oggetti pregiati e potenti). Cercate di aggiungere piu'
interattivita' possibile - rendendo 'viva' la grande maggioranza dei mob (usando le
caratteristiche estese del db di Tempora Sanguinis, che vi permettono di farli parlare,
dare e prendere oggetti dai giocatori, ed assegnare punti esperienza ai pc direttamente
dall'interno del vostro editor di aree), ed arricchendo oggetti e stanze tramite procedure
speciali (che verranno scritte dagli imp, sulla base delle vostre richieste) - e di
ridurre al minimo il numero di mob fissi: piu' mob si muovono, piu' l'area risultera'
divertente, e dara' l'impressione di essere 'viva'.
In particolare, calibrate attentamente la difficolta' dell'area in funzione del livello
dei giocatori cui e' destinata, e cercate di renderla dinamica e divertente, persino nei
combattimenti: mob 'fissi' (che non si muovono dalla loro stanze) vanno assolutamente
evitati, cosi' come vanno evitati dislivelli nell'assegnazione di punti esperienza (ossia,
piazzare uno o due mob molto forti e ricchi in xp, e riempire il resto dell'area con mob
deboli e poco redditizi e' un modo sicuro per far rifiutare la vostra area, o per
costringere gli imp di Tempora Sanguinis a modificarla radicalmente).
In sintesi, il tipo di aree privilegiato da Tempora Sanguinis:
 | e' ricco di mob dotati di una forte interazione, che danno vita a diverse quest,
piu' o meno lunghe (magari anche divise in aree molto lontane tra loro); |
| concede al combattimento un ruolo molto piu' limitato rispetto a quanto avviene
nella maggior parte dei mud, e comunque gli richiede di essere 'vario', vale a dire basato
su un ampio numero di mob in movimento ed in gruppo tra di loro, con delle capacita' di
combattimento evolute (sia attraverso i flag disponibili per i mob, sia attraverso
procedure speciali appositamente scritte) e
dipendenti dalle loro classi (i mob, come i pc, possono appartenere a 13 diverse classi, e
possono essere personaggi normali, eroi o Lord of a Land, il che vi mette a disposizione
un'enorme quantita' di comportamenti differenti... usateli!), e su una distribuzione degli
xp assolutamente omogenea tra i diversi mob; |
| possiede oggetti quanto piu' possibile bilanciati (in maniera che i loro punti di
forza siano compensati da caratteristiche negative) e dotati di caratteristiche uniche e
fantasiose; |
| si basa su stanze dalle descrizioni lunghe e ricche di atmosfera (e, ovviamente,
scritte in una prosa corretta), e varie nei loro comportamenti, grazie ai numerosi flag e
caratteristiche aggiuntive che Tempora Sanguinis mette a disposizione dei suoi autori di
aree. |
Nel proseguio del documento, ognuno di questi punti verra' analizzato ed
approfondito.
|
| Zone. La
maggior parte delle aree saranno composte da un'unica zona. E' comunque possibile far uso
di piu' zone, qualora le dimensioni della propria area superino le 100 stanze, o nel caso
si abbia bisogno di meccanismi particolari, a patto di aver preso accordi preventivi in
tal senso con le Divinita' di Tempora Sanguinis. |
| Stanze. Le descrizioni delle
stanze dovrebbero essere scritte in uno stile ricco ed evocativo, prive di errori o
incertezze sintattiche, cosi' da invogliare i giocatori a proseguire nell'esplorazione, ma
*non* devono sottintendere un 'senso di percorrenza' all'interno dell'area stessa (ad
esempio, una descrizione del tipo: 'Prosegui verso l' interno del castello' e' sbagliata,
perche' risulta infondata nel caso che il giocatore stia in realta' passando in quella
stanza per uscire dal castello). Gli attributi delle stanze dovrebbero rispecchiarne le
proprieta'; le Death Trap
dovrebbero essere inesistenti, e, se proprio ha senso inserirne, vanno segnalate
*chiaramente* ed in maniera non equivoca, di modo che non ci si possa andare se non per
sbaglio. Le stanze Peaceful o No
mob dovrebbero essere ridotte al minimo, o addirittura inesistenti: in ogni caso, se
esistono, la loro esistenza deve essere motivata, e, probabilmente, le stanze stesse
dovrebbero essere riconoscibili. Unica eccezione e' il caso in cui si usi il flag No
mob per impedire ai mob di uscire da una certa parte dell'area: si tenga comunque
presente che un mob, quando insegue un giocatore, ignora il valore di questo flag. Allo
stesso modo, il Sector Type di una
stanza deve rispecchiarne le caratteristiche: ogni stanza al chiuso, oltre ad avere, molto
spesso, Inside come Sector Type, *deve* possedere il flag Indoors.
Le stanze di tipo Tree sono
attraversabili solo dai druidi, per mezzo dello spell 'Tree travel'. Infine, e'
preferibile abbondare nelle extra description,
cosi' da rendere piu' 'interattive' le stanze. Per quanto riguarda le uscite, bisognerebbe
evitare le cosidette 'direzioni illogiche', o riservarle a casi molto particolari e
giustificati (luoghi extra-dimensionali, labirinti, etc.). Questo significa - in parole
povere - che se da una stanza si va a Nord, e poi a Sud, si deve tornare nella stanza di
partenza. Tra le parole chiave dell'uscita *non* vanno inserite le direzioni cardinali, ma
*vanno* inserite parole come 'porta', 'portone', etc. |
| Oggetti. Per quanto riguarda
gli oggetti, le parole chiave
dovrebbero contenere i sostantivi e gli aggettivi presenti nella Short description, ma non
gli articoli e le altre particelle non significative (ad esempio, le Parole chiave di Un
anello rosso dovrebbero essere 'anello rosso'). Anche per gli oggetti, vale il principio
di abbondare nelle extra description. Il bilanciamento
della potenza di un oggetto e' molto difficile:ad esempio, oggetti
con hitroll +2 richiedono gia' diversi contrappesi ; se l' hitroll fosse +3, i contrappesi
richiesti sarebbero enormi, mentre, se fosse ancora superiore, le Divinita' di Tempora
Sanguinis dovrebbero semplicemente cambiarlo. Ma quali sono questi contrappesi? in linea
di massima, oltre a far uso del costo di rent (vedi sotto), bisogna limitare ogni oggetto
a delle classi specifiche, e attribuirgli delle caratteristiche negative di pari entita':
cosi', un anello hitroll +2 dovrebbe essere -20 mana. Proprio perche' il bilanciamento
degli oggetti e' un compito arduo e oneroso, che va considerato contestualmente ad un
elevato numero di fattori, le Divinita' di Tempora Sanguinis non chiedono agli autori di
aree - specie se ai loro primi tentativi - di eseguirlo a perfezione, e usualmente se ne
accollano il compito durante la fase di debug e testing. La Long
Description di un oggetto, che viene visualizzata quando l'oggetto si
trova in terra, dovrebbe nella maggior parte dei casi essere identica alla Short
description, con l'aggiunta di un 'e' qui in terra.' . Ad esempio, l'oggetto di Short
description 'Un anello rosso' potrebbe avrebbe come Long description 'Un anello rosso e'
qui in terra.' (notare il punto alla fine della Long description, che *va* inserito
esplicitamente). L'Action description
ha senso solo per le Wand o Staff - e deve contenere il messaggio che appare al giocatore
quando questi se ne serve attraverso il comando 'use' - e per gli oggetti Audio: in questo
ultimo caso, deve contenere il 'rumore' che l'oggetto produce di tanto in tanto. Per
quanto riguarda il Rent, bisogna
tener presente che il valore definito dal giocatore durante la creazione dell'oggetto
viene diviso per due dal mud (il rent cosi' calcolato possiamo definirlo 'rent reale').
Gli oggetti il cui rent reale e' maggiore di 10,000 monete vengono automaticamente
considerati rari dal mud. Gli oggetti il cui rent reale e' maggiore *o uguale* a 10,000
monete costringono il giocatore a pagare il loro costo di rent reale per ogni giorno di
rent; per tutti gli altri, il rent reale viene semplicemente ignorato, e il giocatore si
limita a pagare il rent globale di 100 monete. Detto in altre parole, un oggetto puo'
pagare rent e *non* essere raro solo se il suo rent reale e' esattamente pari a 10,000
monete. Inoltre, inserendo il valore -1 come costo di Rent, si rende l' oggetto non
rentabile.
In sintesi:
| Rent specificato |
Rent Reale |
| < 20.000 |
Ignorato, perchΦ il rent reale Φ minore di 10.000
monete, e quindi viene ignorato (si paga il rent normale, 100 monete). |
| 20.000 |
Il giocatore paga 10.000 monete di rent, ma l'oggetto
non e' considerato raro. |
| > 20.000 |
Paga la metα del rent specificato, e l'oggetto Φ
considerato raro. |
| -1 |
L'oggetto non e' rentabile. |
Cosi', ad esempio, un oggetto con Rent 50,000 costera' al giocatore 25,000
monete al giorno di rent, e sara' considerato raro. Al contrario, un oggetto con Rent
15,000 non produrra' alcun costo di rent al giocatore (oltre le solite 100 monete
giornaliere). Il peso degli oggetti
viene espresso in etti, e non puo' essere minore di uno (il che significa che anche il
peso di una piuma si arrotonda ad un etto). Il valore
degli oggetti e' una stima 'monetaria' della loro potenza, e viene usato sia dai mob
negozianti che dai personaggi (i quali dispongono di skill e spell appositi per venirne a
conoscenza) nelle operazioni di compravendita: e' dunque compito dell'autore dell'area far
si' che il valore di ogni oggetto ne rifletta l'importanza. Ogni oggetto magico *deve*
avere il flag Magic,
e, molto spesso, almeno uno tra Glow
e Hum; si noti che ogni oggetto con
il flag Magic, Glow o Hum non puo' essere utilizzato dai barbari, e che si richiede agli
autori di limitare *fortemente* il numero di oggetti usabili dai barbari, proprio
attraverso l'uso di tali flag. Sempre per quanto riguarda i flag, bisogna cercare di
selezionare tutti quelli 'coerenti' con l'oggetto che si sta creando; a parte quelli
relativi ai limiti di classe, si consiglia ad esempio di usare quelli indicativi del tipo
di materiale (organico, metallico, e cosi' via). Un flag importante e' quello dell'AutoJunk; esso fa si' che un oggetto, se
si trova nell'inventario o nell'equipaggiamento di un mob, venga distrutto quando
quest'ultimo muore. Esso e' particolarmente importante per i mob parlanti, e va inoltre
assegnato a tutti quegli oggetti che devono essere usabili dai mob, ma non dai pc (armi
particolarmente potenti, e cosi' via). Per quanto riguarda il pannello
Wear, ogni oggetto dovrebbe essere indossabile nella parte del corpo
di sua competenza - anche in piu' parti, volendo (il giocatore potra' usare il comando
'wear <oggetto> <posizione del corpo> per decidere dove indossarlo) - oltre a
possedere il flag Take. Si noti che
questi flag non vengono considerati dai mob: ossia, un oggetto che non possiede il flag
Wield puo' comunque venire assegnato come arma ad un mob, che l'usera' per combattere.
Questo stratagemma era un tempo usato per assegnare ad un mob degli oggetti molto potenti,
il cui uso doveva pero' essere vietato ai giocatori: attualmente quest'esigenza e'
risolta, in maniera piu' pulita, dal flag AutoJunk (vedi sopra). Gli oggetti di tipo Tree e Rock sono, rispettivamente,
gli alberi a cui i druidi possono teleportarsi con i loro spell 'Teleport via plant' e
'Portal via plant', e le rocce che possono animare con lo spell 'Animate Rock'. Per quanto
riguarda la loro inizializzazione,
il numero di copie di un oggetto che puo' esistere sul Mud deve, ovviamente, essere
inversamente proporzionale alla sua potenza: ma anche questo e' uno dei fattori che
rientrano nel difficile calcolo del bilanciamento. Infine, salvo casi particolari, il Room
limit di *ogni* oggetto dovrebbe essere 1.
|
| Mob. Per quanto riguarda i mob, il
problema del bilanciamento si applica a loro esattamente come agli oggetti: anche qui, le
Divinita' di Tempora Sanguinis aiuteranno gli autori provvedendo al loro bilanciamento in
fase di debug e testing. Le regole da rispettare per le Parole
chiave, la Short desc e la Long desc sono esattamente le stesse degli
oggetti. In piu', per ogni mob bisogna scrivere una Mob desc, ossia cio'
che il giocatore vede digitando 'look <nome mob>'. Anche in questo caso, il punto
(.) alla fine della descrizione *va* inserito esplicitamente. Il flag
Sentinel, applicato ai mob, fa in modo che essi non si muovano dalla
loro stanza, mentre il flag Zone ne
limita il movimento alla zona in cui si trovano: normalmente, quest'ultimo flag dovrebbe
essere presente in *tutti* i mob. Si noti che questi due flag perdono di significato
quando il mob si trova ad inseguire un personaggio: in quel caso, infatti, lo inseguira'
dovunque, attraverso *tutto* il mondo dell'Impero Celeste. Da quanto detto, segue che non
ha senso dotare un mob sia del flag Sentinel che di quello Zone. Ogni mob che non abbia il
flag Sentinel si muove automaticamente all' interno di tutto il Mud, o della sola zona se
e' attivato il flag Zone (vale a dire che non c'e' bisogno di attivare nessun flag
'Muoviti'). Il flag Immortal rende
il mob 'inattaccabile': semplicemente, tutti i comandi di attacco dei giocatori a lui
rivolti vengono ignorati. Il flag Huge
indica un mob enorme, non bashabile (un drago, ad esempio): per un minimo di logica, non
ha senso che un mob Huge si trovi in una stanza al chiuso (a meno che non si tratti di un
luogo gigantesco, come una cattedrale). Ogni mob appartiene ad una classe, che si decide
attraverso gli omonimi flag: se non si attiva nessuno di questi flag, il mob e'
considerato un guerriero (proprio come se si attivasse il flag Warrior), mentre, se ne
vengono attivati piu' d'uno, il Mud considera solo il primo. Il
livello del mob e' un parametro importantissimo: difatti il comando
CONSIDER consiglia, o meno, ai giocatori di affrontare un certo mob basandosi proprio sul
suo livello. Dunque, specie nelle aree per personaggi principianti, e' compito dell'autore
fare in modo che il livello dei mob sia pari al livello dei giocatori che dovra'
affrontarli, cosi' da rendere validi i consigli dati dal comando CONSIDER. Punto cruciale
in ogni mob, e nel bilanciamento, e' il numero di xp che
fornisce. Esso puo' venir alterato attraverso il campo Xp Bonus; piu'
alto e' il suo valore, maggiore sara' il numero di xp forniti dal mob. Il valore di questo
campo dovrebbe essere il numero delle abilita' speciali del mob diviso due
(essenzialmente, attacchi particolari come acid breath, drain, etc.): l'idea e' che queste
abilita', rendendo un mob piu' difficile da abbattere, devono anche riflettersi in un
maggior numero di xp forniti ai giocatori. In ogni caso, l'Xp Bonus di un mob del mondo
dell'Impero Celeste non deve mai essere superiore a 10. Inoltre, sebbene sia possibile
inserire anche valori negativi in questo campo, per decidere *direttamente* la quantita'
di xp assegnata da un mob (invece di lasciare al mud il compito di calcolarlo, in base
alle statistiche del mob stesso), noi, Divinita' di Tempora Sanguinis, vietiamo
*assolutamente* di farlo. Tutti gli Xp Bonus negativi verranno semplicemente posti
ad un nuovo valore (da 0 in su, in funzione delle abilita' del mob), esattamente come
accadra' per gli Xp Bonus maggiori di 10. Per quanto riguarda l'inizializzazione
dei mob, per aggiungere piu' sapore all'area, si cerchi di
'caratterizzarli': sia con l'eq (cioe', dando a mob identici equipaggiamenti diversi), sia
con le reazioni. Per disporre piu' mob mobili (cioe' senza flag Sentinel) in stanze
vicine, basta caricarne una sola istanza ponendo il valore Limit al numero di mob
desiderati: essendo mobili, si allontaneranno automaticamente gli uni dagli altri subito
dopo l'inizializzazione dell'area. |
| Mob parlanti. Tempora Sanguinis e'
dotata di una caratteristica unica, i cosiddetti 'mob parlanti'. Per la precisione, si
tratta di mob in grado di interagire con i pc, reagendo a parole dette dai pc ai mob
(usando i comandi ask o tell), o ad oggetti dati dai pc ai mob; la loro reazione puo'
consistere in una o piu' risposte (riferite in tell al pc), in uno o piu' emote del mob,
nel give di uno o piu' oggetti dal mob al pc, nell'assegnazione di punti esperienza dal
mob al pc (un pc puo' ricevere punti esperienza una sola volta da uno stesso mob), o in
una qualsiasi combinazione di queste possibilita'. Tutto questo viene realizzato
direttamente tramite db (e quindi
puo' venir gestito dagli appositi editor di aree), senza alcun bisogno di codice
aggiuntivo (non ci sono procedure speciali che devono essere aggiunte al mud, ne' si
richiede all'autore dell' area alcuna conoscenza di programmazione). Perche' i mob possano
dare ai pc degli oggetti, essi devono possederli (ossia, gli oggetti devono trovarsi nel
loro inventario o nell'equipaggiamento); in pratica, vanno forniti al mob all'interno
della lista di inizializzazione dell'area.
|
|
